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Executive Summary 


Access 5 is a NASA-led project tasked to recommend the policies, procedures, 
and functional requirements that will ensure High Altitude Long-Endurance 
(HALE) Unmanned Aircraft Systems (UAS) operate as safely as other routine 
users of the National Airspace System (NAS). Four phases or “STEPS” are 
planned to systematically develop the necessary technology, policies and 
regulations to enable manufacturers to apply for Federal Aviation Administration 
(FAA) certification and approval needed to operate their civil UAS in the NAS. 
Current (FY05) effort limits focus to UASs that operate above 43,000 feet (STEP 
1 )- 

In order for UAS to be integrated into the NAS, it is necessary to identify the 
human systems integration requirements that ensure safe operations in the NAS. 
As a result, the Human System Integration (HSI) Work Package was established 
within the overall Access 5 program to address this objective. In FY05, several 
HSI products were developed to contribute to overall program objectives. 

This product involves definition of technology interface requirements for 
Command, Control, and Communications (C3). This was performed through a 
review of C3-related, HSI requirements documents, standards, and 
recommended practices. Technology concepts in use by the C3 WP were 
assessed also. 


Research of human capabilities and limitations known for C3 was performed 
through a review of Human-System Integration (HSI) requirements documents, 
standards, and recommended practices. 

Technology concepts in use by the C3 WP were assessed. 

Beginning with the HSI high-level functional requirement for C3, and C3 
technology elements, HSI requirements for the interface to the pilot were 
identified. Results of the analysis describe (1) the information required by the 
pilot to have knowledge C3 system status, and (2) the control capability needed 
by the pilot to obtain C3 information. Fundamentally, these requirements provide 
the candidate C3 technology concepts with the necessary human-related 
elements to make them compatible with human capabilities and limitations. The 
results of the analysis describe how C3 operations and functions should interface 
with the pilot to provide the necessary C3 functionality to the UA-pilot system. 

Requirements and guidelines for C3 are partitioned into three categories: (1) 
Pilot-Air Traffic Control (ATC) Voice Communications (2) Pilot-ATC Data 
Communications, and (3) command and control of the unmanned aircraft (UA). 
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Each requirement is stated and is supported with a rationale and associated 
reference(s). 
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Acronym List 


ATC 

Air Traffic Control 

ACS 

Aircraft Control Station 

BLOS 

Beyond Line of Sight 

C2 

Command and Control 

C3 

Command, Control, and Communications 

FAA 

Federal Aviation Administration 

FAR 

Federal Aviation Regulation 

FL 

Flight Level 

FRD 

Functional Requirements Document 

HSI 

Human System Integration 

LOS 

Line of Sight 

NAS 

National Airspace System 

NASA 

National Aeronautics and Space Administration 

UA 

Unmanned Aircraft 

WP 

Work Package 
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l. Introduction 


1.1. Background 

Access 5 is a NASA-led project tasked to recommend the policies, procedures, 
and functional requirements that will ensure High Altitude Long-Endurance 
(HALE) Unmanned Aircraft Systems (UAS) operate as safely as other routine 
users of the National Airspace System (NAS). Four phases or “STEPS” are 
planned to systematically develop the necessary technology, policies and 
regulations to enable manufacturers to apply for Federal Aviation Administration 
(FAA) certification and approval needed to operate their civil UAS in the NAS. 
Current (FY05) effort limits focus to UASs that operate above 43,000 feet (STEP 
1 ). 

In order for UAS to be integrated into the NAS, it is necessary to identify the 
human systems integration requirements that ensure safe operations in the NAS. 
As a result, the Human System Integration (HSI) Work Package was established 
within the overall Access 5 program to address this objective. In FY05, several 
HSI products were developed to contribute to overall program objectives. The 
FY05 HSI effort followed a standard, HSI process methodology that produced the 
following deliverables (Figure 1): 

Deliverable 1: Human System Integration Step 1 Functional Requirement 
Document (FRD) 

Deliverable 2: Human System Integration (HSI) Step 1 Design Guidelines for the 
Unmanned Aircraft System (UAS) Ground Control Station 

Deliverable 3: High Altitude Long Endurance (HALE) Unmanned Aircraft System 
(UAS) Pilot Rating Criteria (Draft) 

Deliverable 4: HSI Requirements and Guidelines for Experimental Certification of 
the Unmanned Aircraft System 

Deliverable 5: Human Systems Integration Step 1 Pilot-Technology Interface 
Requirements 

Deliverable 5a: Human Systems Integration Step 1 Pilot-Technology 
Interface Requirements for Command, Control, and Communications (C3) 
in Unmanned Aircraft Systems 

Deliverable 5b: Human Systems Integration Step 1 Pilot-Technology 
Interface Requirements for Collision Avoidance in Unmanned Aircraft 
Systems 

The following document was prepared by a collaborative team through the noted work package. This 
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Deliverable 5c: Human Systems Integration Step 1 Pilot-Technology 
Interface Requirements for Contingency Management System in 
Unmanned Aircraft Systems 


Deliverable 5d: Human Systems Integration Step 1 Pilot-Technology 
Interface Requirements for the Weather System in Unmanned Aircraft 
Systems 

Deliverable 6: Human Systems Integration Support to Simulation and 
Flight Test for Step 1 
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Figure 1 . FY05 HSI Process and Deliverable Overview 


2 . Document Purpose 

The purpose of this document is to define HSI technology interface requirements 
for C3. 
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Research of human capabilities and limitations known for C3 was performed 
through a review of Human-System Integration (HSI) requirements documents, 
standards, and recommended practices. 

Technology concepts in use by the C3 WP were assessed. 

Beginning with the HSI high-level functional requirement for C3, and C3 
technology elements, HSI requirements for the interface to the pilot were 
identified. Results of the analysis describe (1) the information required by the 
pilot to have knowledge C3 system status, and (2) the control capability needed 
by the pilot to obtain C3 information. Fundamentally, these requirements provide 
the candidate C3 technology concepts with the necessary human-related 
elements to make them compatible with human capabilities and limitations. The 
results of the analysis describe how C3 operations and functions should interface 
with the pilot to provide the necessary C3 functionality to the UA-pilot system. 

Requirements and guidelines for C3 are partitioned into three categories: (1) 
Pilot-Air Traffic Control (ATC) Voice Communications (2) Pilot-ATC Data 
Communications, and (3) command and control of the unmanned aircraft (UA). 

Each requirement is stated and is supported with a rationale and associated 
reference(s). 
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3. Scope 


3.1. Ground Rules 

3.1.1. Requirements are based on Access 5 Program 
Command, Control, and Communications (C3) Work 
Package (WP) requirements and concepts as well as HSI 
standards and recommended practices. 

3.1.2. Requirements defined are for the Access 5 program, 
Step 1, which limits scope to C3 only for flight above 
FL430. 

3.1.3. Domestic Reduced Vertical Separation Minima 
(RVSM) rules are not considered as part of the study. 

3.1.4. HSI Requirement Verification for dynamic operations 
(e.g., communications with air traffic control (ATC)) requires 
verification in a dynamic environment, i.e. , simulation or 
flight test. HSI Requirement Verification for static 
operations (e.g., description of a control function) does not 
require verification in a dynamic environment, e.g., to be 
verified by analysis. 

3.1.5. Requirements defined are independent of any design 
solution except those specified by the C3 WP. 

3.1.6. No distinction is made between C3 requirements for 
line-of-sight (LOS) and beyond-line-of-sight (BLOS) HSI 
requirements 

3.1.7. Requirements do not address: Aircraft equipped with 
ATC datalink capability. 

3.1.8. In accordance with FARs and standard operating 
practices, there is no requirement for air-to-air voice (i.e., 
aircraft-to-aircraft) communications. 
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3.2. Assumptions 


3.2.1. System operation is normal, all modes are fully- 
operational, no inhibits are active, and there are no partial 
failures. 

3.2.2. The pilot will have all necessary control and display 
capabilities in the Aircraft Control Station (ACS) to satisfy 
HSI requirements. 


4. Method 

Research and documentation of human capabilities and 
limitations known for C3 was performed through a review of 
HSI requirements documents, standards, and recommended 
practices. Sources examined include Society of Automotive 
Engineers Aerospace Recommended Practices and Aerospace 
Resource Documents; FAA regulatory and advisory material; 
FAA Human Factors Design Guide; other key research papers. 

The technology concepts in use by the C3 WP were assessed. 
These include voice communication between the UA pilot at the 
ACS and the air traffic controller for line of sight (LOS) and 
beyond line of sight (BLOS) (using communications satellite(s) 
and UA as a relay node), and data transmission using digital 
uplink and downlink for communication between the pilot at the 
ACS and the UA. 

For these C3 technology elements, HSI requirements for the 
interface to the pilot (in the form of pilot information and control 
requirements) were identified. Fundamentally, these 
requirements provide the candidate technology concepts with 
the necessary human-related elements to make them 
compatible with human capabilities and limitations. 

5. Technology Interface Requirements 

The HSI FRD describes the highest level functional 
requirement for communication as follows: “The Human System 
Interface shall enable the pilot to communicate with ATC.” 1 
Technology interface requirements in this document fall under 
this requirement. 


1 Step 1: Human System Integration (HSI) Functional Requirements Document (FRD), Version 
1.1, July 2005. 
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Technology interface requirements are a necessary element of 
the HSI functional decomposition analysis of C3 Functional and 
Performance requirements. The results of the analysis describe 
how C3 operations and functions should interface with the pilot 
to provide the necessary C3 functionality to the UA-pilot 
system. 

They represent high-level, requirements for (1) pilot control of a 
C3 system and (2) information required by the pilot to 
understand vehicle operation. 

Requirements and guidelines are partitioned into three 
categories: (1) Pilot-ATC voice communications, (2) Pilot-ATC 
data communications and (3) Pilot-UA command and control. 

Each requirement is stated and is supported with a rationale 
and associated reference(s). 

5.1 . Pilot-ATC Voice Communications 

5.1.1. Pilot-ATC Latency (Control Requirement). The time 
delay between pilot transmission from the ACS to reception 
by the air traffic controller and controller transmission to the 
pilot at the ACS shall not adversely affect ATC 
communications, air traffic controller functions, tasks, or 
workload. Neither shall it adversely affect pilot functions, 
tasks, and workload. The requirements for the pilot-ATC 
air-ground communications system shall limit voice delay to 
TBD ms. This delay represents the elapsed time from when 
the pilot or controller begins to speak until the audio signal 
is received by the listener. 

5.1 .1 .1 . Rationale. In the ATC environment, controllers and 
pilots have adopted a standard phraseology for 
conducting spoken dialogues to ensure a minimum 
possibility of error or misunderstanding. ATC 
communications safety measures, such as proper 
timing and read backs, assure that communication is 
taking place correctly. Non-standard delays in 
communications adversely affect operations and 
safety: First, delays may increase the total amount of 
time devoted to complete required communications 
tasks. Second, delays may increase the rate of 
deviations from the standard phraseology and 
procedures (e.g., partial or missing read backs) if 
words or pilot responses are omitted to shorten the 
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dialogues. Third, delays may result in more 

simultaneous transmissions or retransmissions if the 
expected time window for a response is exceeded. 
Finally, delays may result in the untimely delivery of 
messages as longer transactions are crowded onto a 
congested communications channel. In addition, other 
unwanted effects may appears including user 

frustration, greater variability in aircraft flight paths, 
blocked transmissions, and reduction in ATC service. 2 

5.1.2. Pilot Identification of the Active Radio in ACS (Display 
Requirement). The pilot shall have the capability to 
determine the radio in use by referring to displays and/or 
indicators in the ACS. 

5.1 .2.1 . Rationale. Display only and all the necessary data 
to the pilot and ensure that radio usage data the pilot 
needs are available for display. 3 

5.1.3. Pilot Control of ACS Radio Functions (Control 
Requirement). The pilot shall have capability to operate the 
radio at the ACS. This includes capability to turn the radio 
on and off, select any frequency assigned by ATC for 
transmission and reception, adjust reception volume, and 
select radio modes. 

5. 1.3.1. Rationale. Operation of the radio, including the 
requisite control functions, is necessary in order to 
communicate with air traffic control. 4 

5.1.4. ACS Display of Radio Functions (Display 
Requirement). The pilot shall have capability to receive 
feedback regarding radio operation at the ACS. This 
includes capability to know radio on and off status, display 
of frequency selected for transmission and reception, 
reception volume setting, and radio modes (subject to radio 
design). 

5. 1.4.1. Rationale. Operation of the radio, including the 
requisite information content, is necessary in order to 
communicate with air traffic control. Display only and 

2 The Effect of Voice Communications Latency in High Density, Communications-lntensive 
Airspace. Federal Aviation Administration, Atlantic City, NJ. January, 2003. 

3 Human Factors Design Guidelines for Multifunction Displays, DOT/FAA/AM-OI/17, Office of 
Aerospace Medicine, 2001, para. 3.1. 

4 Human Factors Design Guide Update, Report Number DOT/FAA/CT-96/01 . Federal Aviation 

Administration, Washington, D.C. June, 2003. Sect. 7.4.5. 
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all the necessary data to the pilot to ensure that radio 
usage data the pilot needs are available for display. 5 

5.1.5. Pilot Knowledge of LOS or BLOS Status (Display 
Requirement). The ACS shall display to the pilot the LOS 
and BLOS status of communications. 

5. 1.5.1. Rationale. The pilot needs to know whether the 
system is operating LOS or BLOS. Display only and all 
the necessary data to the pilot to ensure that radio and 
datalink usage data the pilot needs are available for 
display. 6 

5.2. Pilot-ATC Data Communications 

5.2.1. Pilot Control of ACS UA Transponder (Control 
Requirement). The pilot shall have capability to control the 
aircraft transponder at the ACS. This includes capability to 
turn the transponder on and off, select any code assigned 
by ATC, select codes 7600 and 7700, activate the IDENT 
function, and select transponder modes. 

5.2. 1.1. Rationale. Operation of the transponder, including 
the requisite control functions, is necessary in order to 
communicate with air traffic control and some airborne 
collision avoidance systems. 7 

5.2.2. ACS Display of UA Transponder Functions (Display 
Requirement). The ACS shall display feedback to the pilot 
regarding transponder operation at the ACS. This includes 
capability to present transponder on and off status, display 
of code selected, and transponder modes. 

5. 2. 2.1. Rationale. Operation of the transponder, including 
the requisite information content, is necessary in order 
to communicate with air traffic control and some 
collision avoidance systems in other aircraft. Display 
only and all the necessary data to the pilot to ensure 


5 Human Factors Design Guidelines for Multifunction Displays, DOT/FAA/AM-OI/17, Office of 
Aerospace Medicine, 2001, para. 3.1. 

6 Human Factors Design Guidelines for Multifunction Displays, DOT/FAA/AM-OI/17, Office of 
Aerospace Medicine, 2001, para. 3.1. 

7 Human Factors Design Guide Update, Report Number DOT/FAA/CT-96/01 . Federal Aviation 

Administration, Washington, D.C. June, 2003. Sect. 7.4.5. 
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that transponder usage data the pilot needs are 
available for display. 8 

5.3. Command and Control (C2) 

5.3.1. Pilot Control of Flight Path or Trajectory (Control 
Requirement). The pilot shall have control capability at the 
ACS to authorize datalink actions prior to enabling control 
of the vehicle flight path or trajectory. 

5.3.1 .1 . Rationale. As the pilot is the final authority for safe 
operation of the aircraft, the pilot must have the ability 
to control the state of the flight control system and any 
related system(s) that affect control over flight path or 
trajectory. 

5.3.2. ACS Display of Flight Path Information (Display 
Requirement). The pilot shall have information available at 
the ACS that indicates authorized datalink actions prior to 
enabling control of the vehicle flight path or trajectory. 

5.3.2. 1 . Rationale. As the pilot is the final authority for safe 
operation of the aircraft, the pilot must have the ability 
to know the state of the flight control system and any 
related system(s) that affect flight path or trajectory. 
The pilot must maintain specific situation awareness 
so that manual or automatic flight control is affected 
safely 9 . 

5.3.3. Pilot-Vehicle (Flight Control System (FCS)) Coupling 
(Control and Display Requirement). The pilot shall have 
information and control capability so that pilot-UA 
interactions are not adverse, unfavorable, nor compromise 
safety. Unfavorable interactions include anomalous aircraft- 
pilot coupling (APC) interactions (closed loop), pilot- 
involved oscillations (categories I, II or III), and non- 
oscillatory APC events (e.g., divergence). 

5. 3. 3.1. Rationale. For UA that require some element of 
manual control in LOS or BLOS operation, either as a 
primary or backup FCS mode, the UAS 
communication link shall not contribute to increased 


Human Factors Design Guidelines for Multifunction Displays, DOT/FAA/AM-OI/17, Office of 
Aerospace Medicine, 2001, para. 3.1. 

9 Human Factors Requirements for Datalink. Air Transport Association Information Transfer 
Subcommittee. June, 1992, Para. 2.6. 
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pilot flight control workload to the extent that pilot- 
vehicle coupling is produced. 10 

5.3.4. ACS Display of Data for System Security (Display 
Requirement).The ACS shall display feedback to the pilot 
regarding the source of downlink transmissions by 
reference to downlink data displayed at the ACS. 

5.3.4. 1. Rationale. The ACS shall display only and all 
necessary data to ensure that datalink security 
information are available to the pilot. 11 

5.3.5. ACS Display of Data Describing Downlink Data 
Corruption (Display Requirement). The pilot shall not be 
presented with downlink data on ACS displays that have 
been corrupted, as determined by a datalink system 
function that checks the integrity of the downlink data prior 
to its display to the pilot. 

5. 3. 5.1. Rationale. The level of data integrity must be high 
enough to ensure that the message that appears on 
the ACS display accurately and completely represents 
output from the vehicle 12 . 

5.3.6. ACS Display of Data Describing Downlink Error 
Checking (Display Requirement). To the extent that the 
datalink system may be unable to detect certain types of 
errors, the ACS shall display feedback to the pilot regarding 
reasonableness of data so the pilot may determine 
implications for operation of the vehicle. 

5.3.6. 1 . Rationale. If a datalink system cannot check 1 00% 
of downlink data for security and correctness, a 
backup means of error checking is necessary. The 
pilot can serve this function at the ACS by inspection 
of data parameters related to the downlink as well as 
other systems. To the extent that the pilot is assigned 


1 0 

Aviation safety and Pilot Control. - Understanding and Preventing Unfavorable Pilot-Vehicle 
Interactions. National Research Council - Committee on the Effects of Aircraft-Pilot Coupling on 
Flight Safety. National Academy Press. 1997. 

11 Human Factors Design Guidelines for Multifunction Displays, DOT/FAA/AM-OI/17, Office of 
Aerospace Medicine, 2001, para. 3.1. 

12 Human Factors Requirements for Datalink. Air Transport Association Information Transfer 

Subcommittee. June, 1992, Para. 4,2, 5.1.3. 
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this responsibility, procedures are required to ensure 
proper pilot performance 13 . 


5.3.7. ACS Display of Data Describing Error Messages in 
Response to Unrecognized Pilot Entry (Control and Display 
Requirement). Any unrecognized entry made by the pilot at 
the ACS shall cause an informative error message to be 
displayed and not affect the status or operation of any 
system. 

5.3.7. 1 . Rationale. When the operator attempts to make an 
entry that the system cannot process, (1) an error 
message should be displayed to the pilot so the pilot 
clearly understands the nature of the error and is able 
to take corrective action. In addition, (2) no such 
erroneous entry should affect systems operation as 
the entry made by the pilot may be misinterpreted by 
the system and result in an inadvertent system 
operation and safety impact 14 . 

5.3.8. ACS Display of Data Describing Downlink Data 
Corruption (Display Requirement). The ACS shall display 
feedback of downlink data corruption. 

5. 3. 8.1. Rationale. As the pilot will be involved in many 
ACS operations, it is not expected that the pilot will 
monitor datalink system status at all times. Humans 
are poor monitors over extended period of time. As a 
result, augmentation of pilot monitoring skill is required 
in the form of a visual alert and/or aural alert to inform 
the pilot of a change in system operational status. 15 16 

5.3.9. ACS Display of Data Describing Datalink Feedback in 
Response to a Pilot Data Entry (Display Requirement). The 
ACS shall display timely feedback to the pilot regarding the 


13 Human Factors Requirements for Datalink. Air Transport Association Information Transfer 
Subcommittee. June, 1992, Para. 3.1. 

Human Factors Design Guide Update, Report Number DOT/FAA/CT-96/01 . Federal Aviation 
Administration, Washington, D.C. June, 2003. 

14 Human Factors Requirements for Datalink. Air Transport Association Information Transfer 

Subcommittee. June, 1992, Para. 5.2.3. 

15 Human Interface Criteria for Cockpit Display of Traffic Information, Aerospace Recommended 
Practice (ARP) 5365. 1999, para. 4.5, 9.1 .1 .7. 

Human Factors Design Guide Update, Report Number DOT/FAA/CT-96/01. Federal Aviation 
Administration. 2002, para. 5.8.2, 5.1.16, 5.3.3, 5.3.4, 5.5.7, sect. 5.6, 5.7. 

16 Human Factors Design Guide Update, Report Number DOT/FAA/CT-96/01. Federal Aviation 

Administration, Washington, D.C. June, 2003. Sect. 7.1.1. 
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content of a command and when a command has been 
entered into the system. 


5. 3. 9.1. Rationale. Feedback provided to the pilot should 
appear in a timely manner, such that (1) the pilot has 
no doubt that the entered command (which generates 
feedback) is as intended, (2) a command is recognized 
by the system, (3) the pilot can determine whether 
further action is required, and (4) is not unsure of 
system status leading to an erroneous double 
command entry 17 . 

5.3.10. ACS Display of Data Describing Arrival of a Datalink 
Message (Display Requirement). The ACS shall display 
feedback to the pilot when a datalink message arrives by a 
visual and/or aural alert. 

5.3.10.1. Rationale. As the pilot will be involved in many 
ACS operations, it is not expected that the pilot will 
monitor the datalink system at all times. Humans are 
poor monitors over extended period of time. As a 
result, augmentation of pilot monitoring skill is required 
in the form of a visual alert and/or aural alert to inform 
the pilot of a change in system operational status. 18 19 


5.3.11. ACS Display of Data Describing Datalink Quality 
(Display Requirement). The ACS shall display feedback to 
the pilot regarding the status or quality of each uplink and 
downlink. 

5.3.1 1 .1 . Rationale. Display only and all the necessary data 
to the pilot and ensure that datalink quality data will be 
available for display. 21 


17 Human Factors Requirements for Datalink. Air Transport Association Information Transfer 
Subcommittee. June, 1992, Para. 5.2.1. 

18 Human Interface Criteria for Cockpit Display of Traffic Information, Aerospace Recommended 
Practice (ARP) 5365. 1999, para. 4.5, 9.1 .1 .7. 

Human Factors Design Guide Update, Report Number DOT/FAA/CT-96/01 . Federal Aviation 
Administration. 2002, para. 5.8.2, 5.1.16, 5.3.3, 5.3.4, 5.5.7, sect. 5.6, 5.7. 

19 Human Factors Design Guide Update, Report Number DOT/FAA/CT-96/01. Federal Aviation 
Administration, Washington, D.C. June, 2003. Sect. 7.1.1. 

on 

“ Human Factors Design Guide Update, Report Number DOT/FAA/CT-96/01. Federal Aviation 
Administration, Washington, D.C. June, 2003. Sect. 7.1.2. 

21 Human Factors Design Guidelines for Multifunction Displays, DOT/FAA/AM-OI/17, Office of 
Aerospace Medicine, 2001, para. 3.1. 
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5.3.12. ACS Display of Data Describing Datalink 
Status/Quality Failure (Display Requirement). The ACS 
shall display feedback to the pilot for any partial or full 
failure of a datalink. 

5.3.12.1. Rationale. As the pilot will be involved in many 
ACS operations, it is not expected that the pilot will 
monitor the datalink status display at all times. 
Humans are poor monitors over extended period of 
time. As a result, augmentation of pilot monitoring skill 
is required in the form of a master visual alert and/or 
aural alert to warn the pilot of a datalink failure 22 . In 
addition, a message should be presented to the pilot 
on ACS displays or indicators describing which 
datalink has failed and the extent of the failure, as 
appropriate . 

5.3.13. Reliability of ACS Display of Data Describing Datalink 
Status/Quality Failure Alert (Display Requirement). The 
datalink status/quality failure alert provided to the pilot at 
the ACS shall not itself be subject to a silent failure. 

5.3.13.1. Rationale. To ensure that the pilot is informed if 
any part of the datalink system malfunctions, a datalink 
alerting function is required that itself does not fail with 
the datalink 24 . 

6. Future Work 

6.1. Step 1 Lower Level Information and Control Requirements. 

The requirements described in this document represent a high 
level definition for pilot information and control capability. 
Future work is required to continue this analysis to the level 
appropriate to the needs of the program and its customers, 


22 Human Factors Design Guide Update, Report Number DOT/FAA/CT-96/01 . Federal Aviation 
Administration. 2002, para. 7. 1.1.1. 

Human Interface Criteria for Collision Avoidance Systems in Transport Aircraft, Aerospace 
Recommended Practice (ARP) 4153. Society of Automotive Engineers. 1988, para. 4a. 

23 Human Factors Requirements for Datalink. Air Transport Association Information Transfer 
Subcommittee. June, 1992, Para. 5.8.3. 

Human Factors Design Guide Update, Report Number DOT/FAA/CT-96/01. Federal Aviation 
Administration, Washington, D.C. June, 2003. Sect. 7.1.1. 

24 Human Factors Requirements for Datalink. Air Transport Association Information Transfer 
Subcommittee. June, 1992, Para. 5.8.3. 

Human Factors Design Guide Update, Report Number DOT/FAA/CT-96/01. Federal Aviation 
Administration, Washington, D.C. June, 2003. Sect. 7.1.1. 
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(e.g., the FAA). Lower level information and control 
requirements will provide the FAA and manufacturers with an 
appropriate level of guidance without restricting the flexibility of 
design. The level of detail required is exemplified in FAR 
23.777, “Means must be provided to indicate to the flight crew 
the tank or function selected.” For Access 5 purposes, an 
analogous information requirement would read, “(For the top- 
level, Aviate functional requirement) A means must be 
provided at the ACS to indicate to the pilot the tank or function 
selected.” Once this level of detail is developed for each top- 
level functional requirement, the information and control 
requirements definition effort for Step 1 will be complete. 

6.2. Step 2, 3, and 4 Information and Control Requirements. 

After work for Step 1 has been completed, information and 
control requirements analyses are necessary for the 
succeeding Steps. The analysis will follow the functional 
requirements developed for these Steps and will focus on 
phases from takeoff to cruise and from cruise to landing. The 
analysis for altitudes between approximately FL180 and 
FL430 will require only minor additions to Step 1 results. 
Significantly new information will be produced from this 
analysis for the critical takeoff, climb, approach, and landing 
phases. 
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